寫著寫著，沒想到已經到鐵人賽倒數篇章了，也該來看一下關於軟體品質（https://zh.wikipedia.org/zh-tw/%E8%BB%9F%E9%AB%94%E5%93%81%E8%B3%AA%E7%AE%A1%E7%90%86 ）。

依據軟體品質保證（Software quality assurance，SQA： https://zh.wikipedia.org/zh-tw/%E8%BD%AF%E4%BB%B6%E8%B4%A8%E9%87%8F%E4%BF%9D%E8%AF%81 ）
SQA涵蓋軟體開發的整個流程，包括如：需求定義、軟體設計、編寫代碼、版本控制、代碼審查、軟體組態管理、軟體測試、發佈管理、產品整合等。SQA主要內容為目標、承諾、能力、活動、測量和驗證。

這麼多項要是真的要嚴格實行，需要相對應足夠的人力與時間去進行，只是我的同溫層，部門其實都蠻窮困的，不要賠，養得起來人，不要砍新來的薪水就了不起，所以通常越後面的階段受限於開發流程就越精簡（慘案大多是，前面階段錢多人多不快搞定客戶，壓縮到後面資源就越來越少，時間也更短，有人被壓搾到不爽離職後，就開始惡性循環），不過倒也可以依項目自己對著看平常真的有對幾項用心去做。

就篇就來看看關於軟體測試、發佈管理這兩個比較後面階段的相關資料吧。

軟體測試（software testing），https://zh.wikipedia.org/zh-tw/%E8%BD%AF%E4%BB%B6%E6%B5%8B%E8%AF%95 ，wiki 寫的蠻不錯的，值得一看。

有兩個比較會被搞混的名詞：QA（品質保證，Quality Assurance，https://zh.wikipedia.org/zh-tw/%E5%93%81%E8%B3%AA%E4%BF%9D%E8%AD%89 ）跟QC（品質控管，Software quality control，https://en.wikipedia.org/wiki/Software_quality_control ）。用「QA vs QC」餵Google，會有更多的說明。進行測試方法的人員是屬於QC的範圍，跟QA做得是不一樣的事情，知道後不要再跟著沒sense的人一起亂喊囉。

通常在規劃時程時，記得保留測試階段的時間Buffer。單元測試我通常把他歸在工程師的開發期間內，萬一開發來不及，就是用減少單元測試項目來給開發做Buffer，把重點放在整合測試上，反正單元項目有bug，整合測試很快就死了，只是通常這段時間大家都會過得很痛苦就是。

通常最重視的會放在SIT跟UAT。在SIT時，記得就要開始跑系統測試，以免UAT時太難看，打壞自己的專案名聲，一點好處都沒有，當user開始覺得廠商能力不足，或無法放心時，更容易放大鏡檢視，而基於一直出錯的立場就沒什麼話好說，很容易一直被凹，搞到大家都不開心。

回歸測試通常發生在上線後需求修改，或產品新增版本功能，但老實說若是沒有自動測試，跟著一次又一次的功能更新，就得重覆，反覆的測試，是消磨熱情最大的敵人（其實就算有做自動化測試，該測試也是得對應版本去修改調整，那個比較省人力還很難說）。但這世界就常發生的就是莫非定律，問題老是出在剛好有點急沒測到，或者是已經測那麼多次了，這次偷懶一下沒關係吧？！然後事情就那麼樣的發生了。也不能怪維護老是待不久，比較有企圖心的禁不起長期阿雜的消耗。

發佈管理應該算是軟體開發的重點成果，不過專案通常比較不看版本，但版控還是會有，因為就只有一個客戶會用。在產品開發時才會比較常見。版本發布有幾個階段，參照wiki： https://zh.wikipedia.org/zh-tw/%E8%BB%9F%E4%BB%B6%E7%89%88%E6%9C%AC%E9%80%B1%E6%9C%9F 。版號也有一些普遍共識下的編法， https://zh.wikipedia.org/zh-tw/%E8%BB%9F%E4%BB%B6%E7%89%88%E6%9C%AC%E8%99%9F 。

通常我都會認大版號為架構性變更或增加大功能；第二版號（小版號）為既有功能增強擴充應用；第三版號為hotfix，推出後有bug或配合系統issue修正的項目。所以在軟體升級時，只升第三版號不用怕；升第二版時要加減看一下release note，看是不是有多什麼設定出來也要一併調整的；升大版號的話，嗯，一定要建測試環境，從原本使用的版號做升級驗證，回歸測試這時就要拿出來嘴一下。

最後要講DevOps（https://zh.wikipedia.org/zh-tw/DevOps ），這個概念跟相關技術已經推廣了有幾年，有基本的成熟度，應該還是有發展空間，但至少已經不是白老鼠了。而這個要作到完整的話，要整合以往各種工程師的技能，說起來是給所有工程師多一個發展路線的選擇。

對於還有前途的產業，應該要去看一下roadmap （https://roadmap.sh/devops ），有規模的公司通常都會自建環境，需求還是會有的。不過重點是要放在導入整體服務，可以順利配合情境整合應用（單一項，或做一半的已經很多都有了）。

DevOps最大的特色就是帶動了PAAS的興起。Cloud computing（https://zh.wikipedia.org/zh-tw/%E9%9B%B2%E7%AB%AF%E9%81%8B%E7%AE%97#%E6%9C%8D%E5%8B%99%E6%A8%A1%E5%BC%8F ） 的服務 IAAS，PAAS，SAAS，就也是紅了好幾年的雲端話題。

整個歷史經歷下來，其實就技術發展也算合理啦，首先是IAAS先出來（虛擬機，公有雲，Infra自建機房建置維運人員改做雲端，技術知識不算差太多），然後基於IAAS，網路速度穩定等因素，很多SAAS就蓬勃發展（原本就很多的各式線上平台服務，最簡單的判斷方式就是輸入帳號密碼就能用的，大多是SAAS）。而PAAS因為大多要用新技術，且通常沒有UI，cmd mode門檻對於使用者來說很高，很難對一般人推行，但是DevOps本來就是一堆工程師在做的事，自然適應力就比較好。

DevOps在我的看法裡，創造出來的工作機會應該是僅次於前端產業（軟體前端有網頁框架，APP（Android，iOS））。我都常說一個爛工程師製造三個工程師職缺，厲害的工程師直接創造一個產業的工程師職缺。所以身為普通工程師的我，要感謝他們創造夠多的職缺，不會讓我失業XD。